前言
到站資訊要「準、穩、能解釋」。測試的目的是：同樣的輸入，三支 API（/bus/routes、/bus/stops、/bus/eta）要回一樣的寫法與可預期的內容；出錯時也要有固定的說法。先把最小必測集合列出來，後面只要定期跑這些用例，就能早點發現資料不新、欄位改名、或來源不穩等問題。

檢查重點
• 狀態碼：成功 200；常見錯誤用 400／404／429／5xx。
• 欄位完整：必備鍵存在（如 routeId, stopId, estimateSeconds, updateTime）。
• 寫法一致：鍵名小駝峰；stopStatus 為 normal|last|suspended|noData。
• 時間正確：updateTime 為 ISO 8601（含 +08:00 或 Z）。
• 單位與範圍：estimateSeconds 為整數秒、不得為負；座標為數字；direction 只許 0/1。
• 新鮮度：updateTime 不要落後太久（依 Day 4 的 SLO 判斷是否「過舊」）。

A. 正常案例
目標：最常見的查詢能穩定成功，欄位與對齊規則都正確。

1. 查路線清單｜輸入：GET /bus/routes?keyword=307｜預期：200；至少一條資料；每筆含 routeId、routeName.zh、updateTime（ISO 8601）。
2. 查某路線去程站點｜輸入：GET /bus/stops?routeId=307&direction=0｜預期：200；回傳 routeId="307"、direction=0；stops 陣列每筆含 stopId、stopName.zh、lat、lon、sequence；updateTime 合規。
3. 查到站預估（對齊成功）｜輸入：GET /bus/eta?routeId=307&stopId=12345&direction=0｜預期：200；含 routeId、stopId、direction、estimateSeconds、stopStatus、updateTime；estimateSeconds >= 0；stopStatus 為可讀值；updateTime 合規；且能對回 /bus/stops。

B. 邊界案例
目標：接近邊界時不崩潰、寫法仍一致。
4. 關鍵字剛好沒命中或只有 1 筆｜輸入：GET /bus/routes?keyword=稀有關鍵字｜預期：200；routes 可為空或很小；不可回 404；欄位與時間仍合規。
5. 路線末端（可能末班或無車）｜輸入：GET /bus/eta?routeId=307&stopId=末端ID&direction=1｜預期：200；stopStatus 可能為 last 或 noData；若不提供 estimateSeconds 可缺省，但 stopStatus 必有；updateTime 合規。
6. 方向必填的路線（不帶 direction）｜輸入：GET /bus/stops?routeId=307｜預期：400；錯誤回應為固定結構（code、message、status、timestamp），訊息點出缺少 direction。

C. 異常案例（
目標：出錯時能說人話，且結構固定，方便畫面顯示與後續追查。
7. 帶錯參數（不存在的 stopId）｜輸入：GET /bus/eta?routeId=307&stopId=____&direction=0｜預期：404；錯誤結構固定（code、message、status、timestamp）；訊息類似「查無資料，請確認路線或站名」。
8. 查太頻繁（超過頻率）｜輸入：對同一 stopId 高頻查詢｜預期：429；錯誤結構固定；message 類似「查詢過於頻繁，稍後再試」；若有 details.retryAfterSeconds 更佳。
9. 來源逾時或暫停｜輸入：模擬上游延遲／無回應｜預期：503 或 504；錯誤結構固定；message 類似「暫無更新，稍後再試」；timestamp 為 ISO 8601。